Web services are the fundamental building blocks in the movement toward distributed computing on the Internet. Open standards and the focus on communication and collaboration among software applications have created an environment where Web services are becoming the platform of choice for application integration. Applications are constructed using multiple Web services from various sources that work together regardless of where they reside or how they are implemented. Web services represent black-box functionality that can be used or reused without the need to know the inner working of Web services. One of the primary advantages of Web services' architecture is that the architecture allows Web services written in different languages on different platforms to communicate with each other with ease via messages. Moreover, a significant number of corporations and companies already have a Web infrastructure and personnel with deep knowledge and experience in maintaining such an infrastructure, thereby allowing more fluid adoption of Web services as a platform for future applications.
Examples of Web services include information sources that one could easily incorporate into applications, such as stock quotes, weather forecasts, sports scores, etc. Beyond information sources, one can imagine a whole class of applications that can be built from Web services to analyze and aggregate information desired by interested persons, and present the information to the interested persons. For example, consider a spreadsheet that summarizes a person's whole financial picture: stocks, 401K, bank accounts, loans, etc. If this information were available through Web services, a spreadsheet application could update the information continuously. While most pieces of information may be available now on the Web in a mixture of incongruous, haphazard elements, Web services make programmatic access to all pieces of information easier and more reliable.
Web services are diverse, but almost all of them have three things in common: (1) Web services expose useful functionality to users via a set of interfaces through a standard protocol, such as Simple Object Access Protocol (SOAP); (2) Web services describe the set of interfaces in a document called a contract using Web Services Description Language (WSDL), which is written in enough detail to allow users to build client applications to talk to Web services; and (3) Web services are registered so that potential users can find Web services easily using Universal Discovery Description and Integration (UDDI). In other words, a Web service is a piece of software exposed on the Web through a particular protocol, described with a particular WSDL contract, and registered in a parcticular location in the UDDI.
As discussed above, a WSDL contract describes interfaces of Web services in enough detail to allow a user to build a client application. More particularly, a WSDL contract is a document that describes a set of messages written in a particular protocol and how these messages are to be exchanged. In other words, a WSDL contract describes a Web service interface in terms of messages the Web service can generate and accept. WSDL contracts are readable and editable, but in most cases, WSDL contracts are intended to be produced and consumed by software.
To see the value of WSDL contracts, consider a user who desires to call a method in a Web service that is provided by one of the user's business partners. The user can obtain from the business partner some sample messages generated and accepted by the method. Then the user can proceed to write an application to produce and consume messages that look like the given sample messages. This technique is fraught with errors, however. For example, the user might see a customer identification “2837” in a message and assume that the identification is an integer when, in fact, it is a string. WSDL contracts specify what a request message must contain and what the response message will look like in an unambiguous notation.
The notation that WSDL contracts use to describe message formats is based-on the XML Schema standard, which is not dependent on any particular programming language, and is suitable for describing Web services interfaces that can be accessible from a wide variety of platforms and programming languages. In addition to describing message content, WSDL contracts define where the service is available and what communications protocol can be used to talk to the service. Thus, a WSDL contract should define everything that is required to write an application to work with a Web service.
Unfortunately, WSDL contracts lack the expressive power to define precisely how an application is to interact with a Web service. Although the term “contract” means a binding agreement between two software entities, an application that is interacting with a Web service is free to ignore the terms of a WSDL contract. Thus, a WSDL contract appears as nothing more than a paper tiger. A system 100 shown in FIG. 1 illustrates this problem in greater detail.
The system 100 includes a client 102, which is a computer that accesses shared network resources being provided by another computer, such as a server 106, on a local area network or wide area network such as the Internet 104. A number of Web services 108, 110, are statically stored on the client 102 and the server 106. Web services 108, 110 are composed of programs 108A, 110A, and WSDL contracts 108B-110B.
Each WSDL contract can be divided into two major sections. The first section contains abstract definitions and the second section contains concrete descriptions. The abstract definitions define contractual elements in a platform-independent and language-independent manner. The abstract definitions do not contain machine-specific or language-specific elements. This helps define a set of services that several diverse Web sites can implement. Site-specific elements, such as data serialization, are relegated to the concrete descriptions. Abstract definitions include definitions for types, messages, and porttypes. The concrete descriptions specify bindings and services. The types section declares data types used in a WSDL contract. The messages section defines parameters to operations (i.e., methods). The porttypes section defines one or more operations that can be invoked by applications (and other Web services) external to a Web service described by a WSDL contract. The bindings section can have one or more binding elements whose purpose is to specify how each call and response to an operation is sent or received over the network 104 in accordance with a protocol. The services section has one or more service elements, each of which contains port elements, and each of which in turn refers to a binding element in the bindings section.
Structure 112 illustrates the relationship among contractual elements of the contract 108B and is shown in block diagram form. A porttype 112D declares a number of operation elements. Operation elements within a porttype define the syntax for calling all methods declared in a porttype, such as a prepare operation 112E, a “do work” operation 112F, and a “clean up” operation 112G. Thus, each operation element in a porttype defines the name of the method, the parameters (using messages), and the type of each parameter. There can be several porttypes within a WSDL contract. Each porttype groups together a number of related operations.
A binding element 112C specifies the protocol, serialization, and encoding to be used for each operation 112E-112G of the porttype 112D. A port element 112B associates an Internet location with the binding 112C in a one-to-one correspondence via the use of a Uniform Resource Locator (URL). A service element 112A contains a set of port elements, such as the port 112B. There can be more than one service element in a WSDL contract. Each service element can be used to group together ports according to a URL destination. For example, a developer can redirect all service requests simply by using another service element, and external Web services can still interact with a Web service. Another use of the service element is to classify the ports according to an underlying protocol. For example, a developer can put all HTTP ports in one service element and all SMTP ports in another. An external Web service can then search the WSDL contract 108B for the service that matches the protocol that it can deal with.
As indicated above, the WSDL contract 108B includes several operations, such as the “prepare” operation 112E, the “do work” operation 112F, and the “clean up” operation 112G, which can be invoked to access the services provided by the Web service 108. However, the “prepare” operation 112E should be invoked before the “do work” operation 112F, and the “do work” operation 112F should be invoked before the invocation of the “clean up” operation 112G. Prior WSDL contracts lack the expressiveness power to communicate this ordering information to other Web services, such as the Web service 110, that may desire the services of the Web service 108. For example, the Web service 110 may choose to initially call the “clean up” operation 112G instead of first invoking the prepare operation 112E. This could be catastrophic to the working of the Web service 108 in that it may corrupt the internal execution state of the Web service 108. Moreover, suppose that the Web service 110 is malicious. In this case, the Web service 110 can exploit this weakness of the Web service 108 by calling operations 112E-112G out of sequence simply to wreak havoc with the proper operation of the Web service 108. If Web services can be inappropriately exploited in this fashion, trustworthiness of Web services will be questioned and their use will be diminished and eventually extinguished from the marketplace.
Thus, there is a need for better methods and systems for allowing Web services to safely interact with other Web services while avoiding or reducing the foregoing and other problems associated with existing Web services.